有些補習班會在要做專題的時候進行分組，既然有分組那就會有組長，因此我會建議從開訓的那一天起開始觀察適合當組長的人選，當然組長也有可能是你。

會希望大家多留意組長是因為組長需要承擔編程以外的組織期待，包含但不限於:

• 了解個別組員的進度
• 了解專題的整體進度
• 專題整題技術選型的溝通
• 幫忙協助後落的組員跟上

以下列出我認為適合當組長的幾個特質:

• 能創造組織凝聚力
• 展現對團隊工作的深切熱情
• 能夠展開有效溝通
• 有足夠的抗壓性

以上的幾個特質都無關技術能力，因為我認為組員會不自覺選擇技術能力強的組長是因為想要組長可以帶領自己變得更強。

經常出現的組織問題

因為看了好幾次的組織危機，所以列出來希望能盡量避免。

我的超人組長(或組員)把專題做完了

組長技術經得起考驗，組員也會期待跟了這個組長實力可以突飛猛進，但這類的組長有時候也會選擇自己默默地將專案做完，雖然專題展示沒問題了，但是組員去面試時該如何面對面試官呢?展現過人的技術是一件好事，但是多少也該考慮到其他組員的需求才是，為了避免這樣的事情發生我才會在一開頭強調適合當組長的人格特質。

會消失的組員與害怕拖累其他人的組員

聽說每個組都有10%的機率組員會消失或是退場。
因為組長沒有實權，所以能不能在一開始就凝聚整個組一起做專題就相當重要，不管團隊有沒有人掉隊都應以鼓勵的方式來推動組員一起進步，進而完成專題製作。

組員也應該盡可能的多表達自己的想法，如果你害怕拖累其他人那就更應該告訴別人自己的困難還沒有完成突破，為自己評估好完成突破的時間，這樣在超過時間之後才有人可以適時的推著你前進，所以把自己推離團隊了。

號稱進度完成實際卻爆炸的組員

大家有想過當一個組員對你說「差不多快完成了」的時候背後代表的完成度有多少嗎??是再一天能完成、剩下3%就完成、或是剩下1%但需要一星期的時間呢?

其實每個人對於一個任務的難度及完成度的想像都不一樣，也因為不一樣才造成了模糊的地帶出現。

檢查了一個說進度完成的組員的功能卻發現一大堆的bug，甚至功能東漏西漏，然後再過一個禮拜就要交專題了，這下該怎麼辦??

這不一定是謊報，只是進度完成的定義與自己所想的不一樣，為了避免這樣的狀況出現，組長跟組員最好在一開始就定義好功能快完成以及已完成的意思，同組之間可以密切的溝通並積極尋找程式碼可以合併的時機點，以降低每個人在進度認知上的誤差。

技術棧沒有統一的專題

技術棧沒有統一專題還是做得出來，甚至出來工作後也會發現有些專案也是混雜著各種技術棧...，但做專題時應該盡量專注在功能的實現，而不是如何合併不同技術棧到一起。

所以組長需要跳出來根據組員的進度，從中找出一個適合自己團隊的技術棧。

改善方向

我認為大部分健康的組織有以下特點

• 資訊盡可能的透明
• 盡可能的訊息交流
• 盡可能的互相幫助

如何掌握專題進度?

最基本的就是讓組員盡可能每天都推進度到代碼託管平台上，例如github。

然後可以的話我會建議每日花15-20分鐘讓所有組員展示當日進度。儘管壓力會比較大，但這樣能確保每個人都有得到一定程度的關注，並且在展示期間就可以產生討論，這樣的討論往往能促進團隊合作。

專題成果重要還是過程重要

我覺得過程比成果重要。
因為我們都是轉職為目的來學習的，但是面試官無法透過專題展示看到每個人負責的部分，所以面試過程中大多會問面試者在專題中負責了哪個部分?學到了什麼?遇到了哪些困難?如何突破這些困難的?

所以專題是一個講述故事的切入點，讓你可以證明你目前具有了哪些能力。

圖片來源: https://www.pexels.com/zh-tw/photo/1595391/